The Unified Extensible Firmware Interface (UEFI) specification defines a boot process that is divided into three general phases: (1) a security phase (SEC); (2) a pre-EFI initialization phase (PEI); and (3) a driver execution environment phase (DXE). SEC performs minimal processing to initialize the CPU and prepare the system for PEI including verifying the platform firmware. PEI then configures the entire platform and loads the DXE. Finally, DXE loads drivers, mounts drives and executes the OS bootloader to eventually transfer control to the OS.
FIG. 1A provides a generalized overview of the components that are involved in the UEFI integrity verification process when a computing device 100 boots. As shown, computing device 100 includes a CPU 101, flash memory 102 which stores platform firmware 105 and storage 103 (e.g., a hard disk or Serial Peripheral Interface (SPI) flash that includes a UEFI firmware volume) that stores UEFI images 110-112.
When computing device 100 is powered on and as part of SEC, CPU 101 verifies that the platform firmware 105 stored in flash 102 has been digitally signed by the original equipment manufacturer (OEM) (e.g., by verifying the Authenticated Code Module (ACM), the Bootguard Key Manifest, the Initial Boot Block (IBB), etc.). As represented by the arrow in FIG. 1A, this verification employs a hash of the OEM's public key that is typically flashed into fuses on the CPU which ensures that only the OEM can modify the platform firmware (i.e., because the platform firmware must be signed using the OEM's private key, it is not possible for others to modify or replace the platform firmware).
Once platform firmware 105 has been verified, and as part of PEI, platform firmware 105 (e.g., a PEI driver) initiates “Secure Boot” to ensure that only trusted UEFI images, such as DXE modules and the OS bootloader, are loaded. With Secure Boot, platform firmware 105 verifies that each UEFI image 110-112 has been properly signed. As represented by the arrows in FIG. 1A, this verification is performed using Secure Boot keys stored in Secure Boot databases that form part of platform firmware 105. The OEM is responsible for creating and storing the Secure Boot keys. A detailed explanation of the verification of UEFI images can be found in section 31.5 of the UEFI Specification, Version 2.7 Errata A.
Each Secure Boot database is in the form of an EFI SIGNATURE LIST structure which includes a number of EFI SIGNATURE DATA structures. Each EFI SIGNATURE DATA structure defines a signature and a GUID representing the owner of the signature (e.g., the provider of the UEFI image). These Secure Boot databases include an authorized database and a forbidden database. Prior to loading a UEFI image, platform firmware 105 will first compare the UEFI image's signature to the signatures in the authorized and forbidden databases. If the UEFI image's signature is included in the authorized database and not included in the forbidden database, the platform firmware will load the UEFI image. For example, as shown in FIG. 1A, the authorized database includes signatures 110a, 111a and 112a among possibly many others. Therefore, any UEFI image that has a valid signature matching any of these signatures in the authorized database will be allowed to load.
Accordingly, if the OEM desires to add a DXE module (e.g., a UEFI wireless driver), it is necessary to update platform firmware 105 by including the DXE module's signature in the authorized database. In other words, a Secure Boot key corresponding to the added DXE module must be added to the Secure Boot databases. Since this modification to the Secure Boot databases is a modification to platform firmware 105, it will be necessary to sign the modified platform firmware using the OEM's private key and then write the modified and signed platform firmware to flash 102. This requirement to flash the entire platform firmware whenever a Secure Boot key is added to the Secure Boot databases is cumbersome. However, if the platform firmware is not updated to include the Secure Boot key corresponding to an added DXE module, the DXE module will fail the PEI verification process and will not be loaded (i.e., the authorized database will not include the signature of the added DXE module).
FIG. 1B illustrates this requirement to flash the entire platform firmware 105 whenever a Secure Boot key is added to the Secure Boot databases. As shown, a new UEFI image 113 has been added to storage 103. UEFI image 113 would need to be signed using the provider's private key and then the appropriate Secure Boot key including signature 113a would need to be added to the Secure Boot databases that form part of platform firmware 105 on flash 102. The same would be true if any existing UEFI image is updated.
The Secure Boot key for the new UEFI image 113 cannot simply be added to the existing platform firmware 105 because the addition would cause the existing signature to no longer be valid. Therefore, in addition to adding the Secure Boot key to the Secure Boot databases, the OEM will need to sign the updated platform firmware 105a and then write the updated platform firmware 105a to flash 102. This will ensure that CPU 101 will verify the updated platform firmware 105a using the OEM public key.